Quantization of Data Streams of Instrumented Software

ABSTRACT

A data analysis system processes data generated by instrumented software. The data analysis system receives data streams generated by instances of instrumented software executing on systems. The data analysis system also receives metadata describing data streams. The data analysis system receives an expression based on the metadata. The data analysis system receives data of data streams for each time interval and computes the result of the expression based on the received data values. The data analysis system repeats these steps for each time interval. The data analysis system may quantize data values of data streams for each time interval by generating an aggregate value for the time interval based on data received for each data stream for that time interval. The data analysis system evaluates the expression using the quantized data for the time interval.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.15/799,049, filed on Oct. 31, 2017, which is a continuation of U.S.application Ser. No. 14/800,679 (now U.S. Pat. No. 9,804,951), filed onJul. 15, 2015, which claims the benefits of U.S. Provisional ApplicationNo. 62/061,616, filed on Oct. 8, 2014, U.S. Provisional Application No.62/094,935 filed on Dec. 19, 2014, and U.S. Provisional 62/109,308 filedon Jan. 29, 2015, each of which is incorporated herein by reference inits entirety.

BACKGROUND

The disclosure relates to instrumentation of software in general andmore specifically to generating regular data streams with data valuesoccurring at fixed time intervals from irregular data streams generatedby instrumented software.

Software developers monitor different aspects of software they developby instrumenting the code. These include performance of the software,errors encountered during execution of the software, significant eventsencountered during execution of the software, information describingwhich parts of code are being executed and which parts are not beingexecuted, and so on. Conventional techniques for instrumenting codeinclude statements in the code that log different types of informationto log files or print information on screens. This type ofinstrumentation is suitable for simple applications, for example,applications having a simple flow of execution that execute on a singleprocessor. However, these techniques for instrumenting software areinadequate for complex applications that may be distributed acrossmultiple systems, each system executing multiple processes or threads ofexecution.

One technique conventionally used for instrumenting such complex systemsis to use help of experts in instrumenting code. Certain vendors provideexpert services that help with instrumentation of code. However, thesevendors typically provide standard services that are often not veryflexible. Furthermore, these vendor based solutions have significantoverhead in terms of time needed by the vendor to instrument code.Accordingly, these solutions are suited towards a slow developmentcycle, for example, a year-long development cycle. However, softwaredevelopment and release cycles for software products have become short.For example, there are several online systems in which softwaredevelopers make changes on a monthly, weekly, or even daily basis anddeploy them. Due to the significant overhead of vendor basedinstrumentation solutions, developers find it difficult to use theseservices in a fast paced development environment.

Furthermore, conventional techniques for instrumenting code causesignificant delays in assimilating the information, storing theinformation, and analyzing the information to generate reports. As aresult, there can be significant delay between the time that a problemoccurs in the software and the time that the problem is detected viainstrumentation of the code. Accordingly, conventional systems forgenerating reports based on instrumentation of software are ofteninadequate in fast paced development cycles of complex applications.

SUMMARY

Described embodiments process data streams generated by instrumentedsoftware. Software developers include instructions in software beingdeveloped for instrumenting the software. A system receives data streamsgenerated by instances of the instrumented software. Data streamsprovide values of metrics generated by instrumented software. Theinstrumented software generates the values at variable time intervals.For example, a metric may be reported when a particular instruction isexecuted in response to requests from clients. Since client requests maybe received arbitrarily, the software reports the metric at variabletime intervals. The system generates quantized data streamscorresponding to each input data stream. The quantized data stream hasdata values occurring periodically at fixed time intervals. The systemidentifies a function for aggregating the metric for which values areprovided by the input data streams. The system generates the quantizeddata streams by determining an aggregate value for each input datastream for each fixed time interval by applying the identified functionover data values of the input data stream received within the fixed timeinterval. The system further receives a request to evaluate anexpression based on the data values from the input data streams. Thesystem periodically evaluates the expression using the data values ofthe quantized data streams.

The features and advantages described in the specification are not allinclusive and in particular, many additional features and advantageswill be apparent to one of ordinary skill in the art in view of thedrawings, specification, and claims. Moreover, it should be noted thatthe language used in the specification has been principally selected forreadability and instructional purposes, and may not have been selectedto delineate or circumscribe the disclosed subject matter.

BRIEF DESCRIPTION OF DRAWINGS

The disclosed embodiments have other advantages and features which willbe more readily apparent from the detailed description, the appendedclaims, and the accompanying figures (or drawings). A brief introductionof the figures is below.

FIG. 1 shows the overall system environment for reporting based oninstrumented software, according to an embodiment.

FIG. 2 shows the architecture of a system for reporting based oninstrumented software, according to an embodiment.

FIG. 3 shows an example hierarchy of metadata objects specified inassociation with data streams received from executing instances ofinstrumented software, according to an embodiment.

FIG. 4 shows sets of data streams associated with a hierarchy ofmetadata objects, according to an embodiment.

FIG. 5 shows an overall process for generating reports based oninstrumented software, according to an embodiment.

FIG. 6 illustrates a process of quantization of the data streamsreceived from instrumented software, according to an embodiment.

FIG. 7 shows an overall process for combining data of data streamsreceived from various sources, according to an embodiment.

Reference will now be made in detail to several embodiments, examples ofwhich are illustrated in the accompanying figures. It is noted thatwherever practicable similar or like reference numbers may be used inthe figures and may indicate similar or like functionality. The figuresdepict embodiments of the disclosed system (or method) for purposes ofillustration only. One skilled in the art will readily recognize fromthe following description that alternative embodiments of the structuresand methods illustrated herein may be employed without departing fromthe principles described herein.

DETAILED DESCRIPTION Overall System Environment

FIG. 1 shows the overall system environment for reporting based oninstrumented software, according to an embodiment. The overall systemenvironment includes an instrumentation analysis system 100, one or moredevelopment systems 120, an administration system 160, and a reportingsystem 150. In other embodiments, more or less components than thoseindicated in FIG. 1 may be used. For example, development system 120,administration system 160, and reporting system 150 may interact withinstrumentation analysis system 100 via a network (not shown in FIG. 1).Furthermore, there may be more or less instances of each system shown inFIG. 1, for example, there may be multiple reporting systems 150.

FIG. 1 and the other figures use like reference numerals to identifylike elements. A letter after a reference numeral, such as “130 a,”indicates that the text refers specifically to the element having thatparticular reference numeral. A reference numeral in the text without afollowing letter, such as “130,” refers to any or all of the elements inthe figures bearing that reference numeral (e.g. “130” in the textrefers to reference numerals “130 a” and/or “130 b” in the figures).

The instrumentation analysis system 100 receives data comprising valuesof metrics sent by different development systems 120 (theinstrumentation analysis system 100 may also be referred to herein as ananalysis system or a data analysis system; a development system may alsobe referred to herein as an external system). A development system 120executes software that has been instrumented, for example, application130. Although, application 130 is shown in FIG. 1 as an example ofinstrumented software, the techniques disclosed herein are not limitedto application software but are applicable to other kinds of software,for example, server software, software executing on client devices,websites, and so on.

The software executing on a development system 120 is configured to sendinformation generated as a result of instrumenting the software toinstrumentation analysis system 100. For example, the application 130may send data periodically to instrumentation analysis system 100.Different applications 130 may send the same metric or different metricsat different rates. The same application may send different metrics atdifferent rates. An application sends data in the form of data stream(or data streams) to the instrumentation analysis system 100. Datastreams are also referred to herein as time series. The application 130sends data to the instrumentation analysis system 100 by invokingapplication programming interface (API) supported by the instrumentationanalysis system 100.

The application 130 (or any other software) may be instrumented to addcounters or gauges to the application. A counter comprises instructionsthat store a value that is incremented upon occurrence of certain eventin the software. The counter may be used to determine the number oftimes a particular part of the code is executed, for example, a functionor a method, a particular branch of a conditional code, an exception, aloop, and so on.

Typically a counter value changes monotonically, for example, a countervalue may increase monotonically or the counter value may decreasemonotonically. Values of a counter may be compared to determine thechange in the particular counter value at two different points in time.For example, the number of times a particular event occurs within a timeinterval between times t1 and t2 may be determined by computing thechange in a corresponding counter value from t1 to t2. The APIs of theinstrumentation analysis system 100 are invoked by the application 130to periodically send the current value of the counter to theinstrumentation analysis system 100.

Following is an example of instrumented code of an application 130. Thefollowing instruction included in the code being instrumented creates acounter object for tracking count of an action or entities.

counter1=createCounter(source=“web1”, metric=“metric1”);

The above instruction creates a counter object and assigns it to thevariable counter1. The instruction to create the counter also specifiesone or more attribute values. For example, the above createCounterinstruction specifies a source attribute and a metric attribute. Thevalue of the source attribute is specified to be “web1” and the value ofthe metric attribute is specified to be “metric1.” In other words, thecounter object is associated with a source “web1” and metric “metric1.”The counter object created by the application 130 acts as a source of adata stream that the application 130 sends to the instrumentationanalysis system 100. In an embodiment, the source and the metric valuesuniquely identify the data stream associated with the counter (or agauge). In other embodiments, more or fewer key value pairs may be usedto uniquely identify a data stream. For example, multiple servers maysend a data stream associated with a source “web1” and metric “metric1”however each data stream may be uniquely identified by furtherassociating the data stream with information identifying the server, forexample, an IP (internet protocol) address of the server or a uniquename of the server.

Values of one or more of the attributes specified during creation of acounter are received when tuples representing values of the counter aresent by the instrumented code of application 130 to the instrumentationanalysis system 100. For example, the source and metric values arereceived with each tuple of values received in the data stream alongwith the data value being reported. Optionally the tuple of values mayinclude a timestamp, for example, the timestamp when the data valuebeing reported was captured by the instrumented software.

The instrumented code of application 130 may include instructions toupdate the counter value at various places in the code. For example, thecounter counter1 may be incremented by executing the instruction“counter1.increment( )” The counter may be incremented to track variousactions or entities associated with the code. For example, the countermay be incremented whenever a particular function or method is called,the counter may be incremented whenever a particular branch of aconditional expression is executed, the counter may be incrementedwhenever an object of a particular type is created, for example, in aconstructor of an object. The increment instruction of the counter maybe called conditionally, for example, if a function is invoked with aparticular combination of parameters. The application 130 communicatesthe counter value to the instrumentation analysis system 100 by invokingan API of the instrumentation analysis system 100.

A counter defined in the instrumented code may reset itselfperiodically. For example, the counter may be reset after a specifictime interval that is configurable. In this case, the counter valuesreceived may not increase (or decrease) monotonically since the valuemay be reset at the end of an interval. A counter may be cumulative,i.e., the counter does not reset (unless explicit instruction isprovided to reset it.) In this situation, the values of the cumulativecounter change monotonically, i.e., increase (or decrease) monotonicallyunless explicitly reset by a user.

A gauge comprises instructions to measure certain runtimecharacteristics of the application 130, for example, heap size, numberof cache misses or hits, active memory used, CPU (central processingunit) utilization, total time taken to respond to a request, time takento connect to a service, and so on. A gauge may also be used to trackcertain application specific parameters or business related values, forexample, number of transactions, number of users, and so on. The gaugemay be invoked periodically based on an interval that is configurable.The value of the gauge is sent to instrumentation analysis system 100periodically.

The administration system 160 allows a privileged user, for example, asystem administrator to associate data streams with metadata. Theadministration system 160 comprises the administration application 170that provides a user interface for a system administrator to specify themetadata. The metadata comprises properties, for example, name-valuepairs. The instrumentation analysis system 100 receives metadatadescribing data streams and stores the metadata.

The metadata includes attributes describing data streams that may bedistinct from the attributes that are received as part of the datastream itself. For example, the data stream may provide data values ofattribute such as cache hits, cache misses, memory usage, and so on.Whereas the metadata may specify attributes such as data center in whichthe data stream is being executed, the branch of an organizationassociated with the data stream, and so on. The metadata attributes mayalso be received from a source that is different from the source of thedata stream. For example, the data streams may be received fromdevelopments systems 120 whereas the metadata attribute values may bespecified by a system administrator using the administration system 160.

The ability to specify metadata independent of the data received for thedata stream allows the application 130 to be instrumented with lesseramount of information sent with each data stream. More specifically,several attributes may be associated with the data stream using themetadata but only some of the attributes associated with the data streamare sent as tuples by the instrumented software. This reduces the amountof overhead introduced in the application 130 as a result ofinstrumenting the code.

Typically, the metadata attributes associated with a data stream arestatic compared to attributes that are received in the data stream thatchange dynamically. Although the metadata attributes can also change,they change less frequently compared to the attributes received with thedata stream. For example, a server may be assigned from one part of theorganization to another part of the organization, thereby causing ametadata attribute describing the part of organization associated withthe data streams sent by that server to change. However, these changesare less frequent compared to the attributes received with the datastream that can change values every second or every millisecond or morefrequently.

The ability to specify metadata describing data streams independentlyfrom the data received from each data stream provides several benefitsin generating reports based on the data stream. As an example, theinstrumentation analysis system 100 can receive modifications tometadata describing each data stream without requiring any modificationsto the instrumented software of the application 130. As a result, theinstrumentation analysis system 100 receives specifications of newreports and modifications to existing reports and generates resultsbased on the new/modified reports without requiring the developers tomodify applications 130.

This provides for a new paradigm for instrumenting software since thedevelopers do not need to consider the types of reports that will begenerated from the instrumented data while instrumenting the software.The developers simply instrument their software to generate raw dataindependent of the metadata attributes. The metadata attributes can bespecified independent of the data of the data stream. The reportingsystem 150 can use the metadata attributes to combine the data of thedata streams in various ways to generate reports. For example, the rawdata may present load on each server every second. The instrumentationanalysis system 100 can aggregate the load on each server grouped bydatacenter (which is a metadata attribute specified independent of thesources of data streams) and computed as the data streams are arrived.The resulting report may be presented in real time, i.e., updated as thedata of the data streams is received.

Furthermore, persons that are experts at generating reports based on theinstrumented software can be different from the software developers. Forexample, an expert at data analysis who is not a developer can definethe metadata for the data streams and generate reports without beinginvolved in the development process. This is a significant improvementover conventional techniques for instrumenting software that requiremetadata to be encoded in the instrumented code. This is so because theskills required for analyzing data are typically different from theskills required for developing software.

Furthermore, the instrumentation analysis system 100 can also receiveand process reports built on top of existing reports by composingexisting reports and adding new analytics functionality. Theinstrumentation analysis system 100 generates results of the new reportsand sends them for presentation in real-time as the instrumentationanalysis system 100 receives data streams from instrumented software.The instrumentation analysis system 100 generates these additionalreports and modifies existing reports without requiring anymodifications to the instrumented code of application 130. Furthermorenew metadata can be defined for data streams that were previouslyreceived. Accordingly, a new report can be generated that is based ondata that is being received as data streams as well as data that waspreviously stored (before the metadata associated with the data stream).For example, report providing a moving average over a large timeinterval can be generated. This report computes the moving average basedon data that is currently being received as well as data that waspreviously received (before the metadata used in the report wasassociated with the data). And furthermore, these new reports can bedefined without having to modify the instrumented software (byre-instrumenting the software) or having to re-deploy the instrumentedsoftware.

Furthermore, the instrumentation analysis system 100 provides separationof the metadata describing the data streams from the data of the datastreams. Accordingly, the amount of data that needs to be transmittedfrom the development systems 120 to the instrumentation analysis system100 is reduced. Each application 130 transmits only the data values ofthe metrics and information identifying the metric. The metadatainformation is received separately from a source independent of the datasource of the data streams. Accordingly, any amount of metadata may beintroduced without increasing the amount of data of each data stream.

The reporting system 150 may be a client device. The reporting system150 includes a client application 140 that allows a user to interactwith the instrumentation analysis system 100. In an embodiment, theclient application 140 is an internet browser, which may include clientside code (e.g., Java Script) for accessing the instrumentation analysissystem 100. In other embodiments, client application 140 is aproprietary application developed for interacting with theinstrumentation analysis system 100. The report may be generated by theinstrumentation analysis system 100 and sent for presentation via thereporting system 150.

The reporting system 150 can be a conventional computer system (e.g., adesktop or laptop computer), a tablet, or a device having computerfunctionality such as a personal digital assistant (PDA), a mobiletelephone, a smart phone or another suitable device. The reportingsystem 150 interacts with instrumentation analysis system 100 via anetwork. The network may comprise any combination of local area and/orwide area networks, using both wired and/or wireless communicationsystems. In one embodiment, the network uses standard communicationstechnologies and/or protocols.

The instrumentation analysis system 100 may be hosted on a computingsystem that includes one or more processors, memory, secondary storageand input/output controller. The computing system used for hosting theinstrumentation analysis system 100 is typically a server class systemthat uses powerful processors, large memory, and fast input/outputsystems compared to a typical computing system used, for example, as areporting system 150.

In an embodiment, data from several development systems 120 may beconsolidated, for example, by a server and the combined data sent to theinstrumentation analysis system 100. For example, an enterprise mayinstall a server that receives data stream internally from differentdevelopment systems 120 and sends the combined data in a batch form tothe instrumentation analysis system 100 periodically. This allowsefficiency of external communication from the enterprise. However thisconfiguration may result in delay in communicating information to theinstrumentation analysis system 100 and the corresponding delay inreporting data by the reporting system 150.

System Architecture of the Instrumentation Analysis System

FIG. 2 shows the system architecture of the instrumentation analysissystem 100, according to an embodiment. The instrumentation analysissystem 100 includes an interface module 210, a quantization module 240,metadata module 220, metadata store 230, a data point routing module250, an analytics engine 270, and a time series data store 260. In otherembodiments, the instrumentation analysis system 100 may include othermodules not described herein. Functionality indicated as provided by aparticular module may be implemented by other modules instead.

The interface module 210 receives requests from external systems, forexample, development system 120 that communicate with theinstrumentation analysis system 100. The interface module 210 supportsvarious application programming interfaces (APIs) that external systemscan invoke. The interface module 210 can receive and process dataprovided by applications 130 that are instrumented using functionalityprovided by different vendors, so long as the instrumented code sendsthe information in a format that can be processed by the interfacemodule 210. In an embodiment, the interface module 210 supports APIsthat allow developer systems 120 to perform various actions associatedwith data streams, for example, registering a data stream, providingtuples representing data values of the data stream, specifyingattributes associated with a data stream (for example, to add newattributes), and so on.

The interface module 210 receives data in the form of a data stream froma development system 120. The interface module 210 receives data andrepresents it as tuples. A tuple of data received by the interfacemodule comprises various elements including a metric identifier, forexample, a name of the metric corresponding to the tuple and a value ofthe metric. The tuple of data received may further comprise otherelements, for example, a timestamp corresponding to the time that thedata was captured by the application 130 sending the data, one or moreproperties associated with the data. In an embodiment, the timestampassociated with a tuple represents the time that the data value wasreceived by the instrumentation analysis system 100.

The properties associated with the data may be provided in the form ofname, value pairs. These properties may provide additional informationdescribing the data received, for example, information describing thesource of the data such as a host name, server name, device name, orservice name associated with the source, a method or function nameassociated with the data, an application instance identifier, and so on.

In an embodiment, the interface module 210 generates and assigns anidentifier to records received by the interface module 210. Theidentifier is referred to herein as a time series identifier (alsoreferred to herein as a tsid or TSID). A unique time series identifieris assigned to all tuples matching a metric name and a set of propertiesreceived with the tuple. Accordingly, a tuple (metric name, properties,metric value, timestamp) gets mapped to a tuple (tsid, metric value,timestamp). For example, if a tuple provides a metric name ml, and ahostname h1, all tuples with metric name m1 and hostname h1 are assignedthe same time series identifier. Accordingly, the tsid uniquelyidentifies all tuples of a data stream received by the instrumentationanalysis system 100.

The quantization module 240 processes data values received so as totransform an input data stream in which data is available at arbitrarytime intervals to a data stream in which data is available at regulartime intervals. For example, the data values received in an input datastream may occur at irregular interval that may change from oneconsecutive pair of data values received to the next pair of data valuesreceived. However, the quantization module 240 processes the data of thedata stream to generate a data stream with data occurring periodically(at regular time intervals), such as every second, or every 5 seconds,or every 15 seconds, and so on. This process is referred to herein asquantization of the data stream or time series. In an embodiment, theinterface module 210 creates multiple threads or processes, each threador process configured to receive data corresponding to a data stream.Each thread or process invokes the quantization module 240 to performquantization of the data received for each data stream for each timeinterval.

The analytics engine 270 evaluates reports specifying expressions basedon attributes that are received with the data stream and/or attributesthat are specified as part of the metadata. The expression may be basedon various operations, for example, aggregations and transformations. Inan embodiment, the expression aggregates an attribute value receivedwith the data stream over subsequent time intervals.

The attributes associated with an attribute may be considered asbelonging to two sets, a first set of attributes for which values areprovided as part of the data of the data stream and a second set ofattributes for which data values are specified as part of the metadataand stored in the metadata store 230. An expression processed by theanalytics engine 270 may be based on attributes of the first set andattributes of the second set. In other words, the expression may bebased on attributes for which values are received with the data streamas well as attributes specified as part of the metadata. An exampleexpression may compute sum of an attribute value received with the datastream such that the aggregate values are grouped over a metadataattribute. For example, if the data stream sends load of server everysecond for several servers of an organization and there is a metadataattribute “datacenter” associated with each server, an expression maydetermine average load of servers grouped over data centers.

The instrumentation analysis system 100 periodically determines thevalue of the input expression and sends the result for display, forexample, via a client application such as a browser applicationexecuting on a client device. The expression may be obtained bycomposing various functions including aggregations and transformationsin various ways as well as by composing other previously definedexpressions. In an embodiment, the analytics engine 270 parses theexpressions, generates an executable representation of the program, andexecutes the generated representation.

The analytics engine 270 may generate a plurality of output data streamsas a result of evaluation of an expression. For example, assume that theanalytics engine 270 receives and evaluates expression aggregates anattribute value received in the data streams across all input datastreams associated with an organization and groups them aggregate valueover a metadata attribute “datacenter.” Accordingly, the analyticsengine 270 generates as many output data streams as there are distinctvalues of the “datacenter” attribute. Furthermore, the number of outputdata streams generated by the analytics engine 270 can change from onetime interval to another. For example, if a new data center is added tothe organization and becomes active, the number of output data streamscan increase as a result of addition of the new data center. Similarly,if servers of an existing data center are shutdown, the number of outputdata streams can decrease for subsequent time intervals. Accordingly,the analytics engine 270 may generate a dynamically changing number ofoutput streams as a result of evaluating the same expression overdifferent time intervals. The changes to the number of output streamsmay occur as a result of changes to the number of input data streamsover subsequent time intervals or as a result of changes to the datavalues received in the same set of data streams over subsequent timeintervals.

The metadata module 220 receives and stores metadata informationdescribing various data streams received from the development systems120. In an embodiment, the metadata stored in the metadata module 220 isreceived from a user, for example, a system administrator interactingwith the instrumentation analysis system 100 via the clientadministration application 170 of the administration system 170. Themetadata may be represented as name-value pairs. In an embodiment, themetadata is represented as metadata objects, each object defining a setof properties that may be represented as name-value pairs. A set of datastreams may be associated with the metadata object. Accordingly, allproperties represented by the metadata object are associated with eachdata stream that is associated with the metadata object.

The metadata datastore 230 stores the metadata objects and theirassociations with the data streams. The metadata datastore 230 stores anidentifier (ID) for each metadata object and the properties representedby the metadata object. In an embodiment, each data stream is associatedwith a time series identifier that uniquely identifies the data stream.The metadata datastore 230 stores an index that maps each metadataobject to a set of time series identifier values. The metadata datastore230 stores indexes that map various tags (i.e., properties or name-valuepairs) to sets of time series identifier values.

The metadata store 230 may modify a metadata object based oninstructions received. For example, the metadata store 230 may modify,add or delete some properties represented by a metadata object.Alternatively, the metadata store 230 may modify the mapping from ametadata object to a data stream based on instructions received. Forexample, the metadata store 230 may associate a data stream with ametadata object or delete an association between a metadata object and adata stream.

In an embodiment, the metadata store 230 is represented as a relationaldatabase but may be represented as any other type of database or datastore. For example, the metadata store 230 may be a relational databasestoring tables that map metadata object IDs to time series identifiersidentifying data streams. Other database tables may store the propertiesassociated with each metadata object as a mapping from metadata objectID to each property represented as a name-value pair. A property is alsoreferred to herein as metadata tag or a tag.

The time series data store 260 stores data streams received from varioussources, for example, development systems 120. In an embodiment, thetime series data store 260 also stores the data streams after the datais quantized. The time series data store 260 may also store output datastreams generated by the analytics engine 270 as a result of evaluatingexpressions. For example, if an expression results in generation ofplurality of data streams, the analytics engine 270 determines a tsidfor each of these output data streams and stores each output data streamin the time series data store 260.

The time series data store 260 may also store rollup data for each datastream. The time series data store 260 also stores results of variousanalytics requests, for example, results of various reports requested byuser. The analytics engine 270 computes results for certain reports, forexample, moving averages over intervals of time by combining data storedin the time series data store 260 with data obtained as data stream fromvarious sources in real time.

Metadata Representation

In an embodiment, the metadata objects are organized in a hierarchicalfashion, thereby allowing reuse of metadata definitions as well as easein modifying the metadata definitions. FIG. 3 shows an example hierarchyof metadata objects specified in association with data streams receivedfrom executing instances of instrumented software, according to anembodiment. As shown in FIG. 3, each metadata object 310 represents aset of properties. Some of the metadata objects may be defined in theinstrumentation analysis system 100 so that they are available to allusers of the system. Other metadata objects may be defined by users, forexample, by an enterprise that uses the instrumentation analysis system100 for generating reports for instrumented software.

The metadata objects shown in FIG. 3 are organized as a hierarchy.Accordingly, metadata object 310 a is above the metadata object 310 c inthe hierarchy, metadata object 310 b is above the metadata object 310 din hierarchy, and metadata objects 310 a, 310 b, 310 c, and 310 d areall above the metadata object 310 e.

A metadata object includes (i.e., inherits) properties of object abovethe metadata object in the hierarchy. For example, metadata object 310 cinherits property “critical:true” from metadata object 310 a, metadataobject 310 d inherits property “datacenter:east” from metadata object310 b, and metadata object 310 e inherits properties “source:web1,”“datacenter:east,” “metric:errors,” and “critical:true” from metadataobjects that are above the metadata object 310 e.

A metadata object may define additional properties in addition to theproperties inherited from metadata objects above the metadata object inthe hierarchy. For example, metadata object 310 c defines“metric:errors” in addition to the property “critical:true” inheritedfrom metadata object 310 a and metadata object 310 d defines“source:web1,” in addition to the property “datacenter:east,” inheritedfrom metadata object 310 b, and metadata object 310 e defines a newproperty “administrator:admin1” in addition to the properties inheritedfrom the metadata objects above the metadata object 310 e in thehierarchy. However, the metadata object does not have to defineadditional properties other than those inherited from metadata objectsabove that metadata object in the hierarchy.

In an embodiment, metadata objects having the source and metricattributes are also referred to as metric time-series objects (MTSobjects). An MTS metadata object is uniquely identified based on themetric and source values. Accordingly, the metric and source values forma key (e.g., a primary key) for uniquely identifying the MTS object. Anytuple of values defining a data point of a data stream can be associatedwith an MTS object based on the source and metric values of the tuple.In an embodiment, an MTS object X has the set of properties obtained bytaking a union of all the sets of properties of metadata objects abovethe metadata object X in the hierarchy. The metadata objects such as 310a and 310 b that do not specify a source and metric value act asabstract objects for specifying sets of properties (these metadataobjects are also referred to as tags).

A data stream is characterized by a set of properties. The data streamis associated with the metadata object having matching properties.Multiple instances of a metadata object may be created, one for eachdata stream that has the matching set of properties. The propertiesallow the instrumentation analysis system 100 to query MTS objects thatsatisfy certain criteria based on key value pairs. For example, given aset of key value pairs, the instrumentation analysis system 100 canidentify all data streams that match the given set of key value pairs.The data points from these matching data streams may be provided to ananalytics job that evaluates certain expressions based on these datapoints.

FIG. 4 shows sets of data streams associated with the hierarchy ofmetadata objects shown in FIG. 3, according to an embodiment. Thehierarchy of metadata objects shown in FIG. 3 is illustrated using thecorresponding sets of data streams shown in FIG. 4. Assume that eachelliptical shape shown in FIG. 4 represents a set 410 of data streams.Furthermore, any set 410 x (where x represents a variable that can takevalues ‘a’, ‘b’, ‘c’ etc.) shown in FIG. 3 corresponds to a metadataobject 310 x shown in FIG. 3. For example, set 410 a corresponds tometadata object 310 a, set 410 b corresponds to metadata object 310 b,set 410 c corresponds to metadata object 310 c, and so on.

Note that a metadata object 410 may not be associated with any datastream, for example, a metadata object may be added as a modelingconstruct that is not associated with any data stream available at thetime the metadata object was added. However, the mapping from metadataobjects 410 to data streams may be modified. For example, elements maybe added to a set of data streams associated with a metadata object orremoved from the set. Accordingly, even if a metadata object is notassociated with any data stream when the metadata object is added to themetadata store 230, the metadata object may be associated with one ormore data streams at a later stage.

As shown in FIG. 4, set 410 a represents all data streams associatedwith metadata object 310 a and therefore having a property name“critical” having value “true.” A user, for example, a systemadministrator may assign data streams to a metadata object using theadministration system 160. For example, a system administrator maydetermine all data streams determined to be critical for the operationof the enterprise and associate them with the metadata object 310 a.

As another example, set 410 b represents all data streams associatedwith metadata object 310 b and therefore having a property name“datacenter” having value “east.” As mentioned above, a systemadministrator can determine instances of instrumented software executingin a datacenter marked “east” and associate them with the metadataobject 310 b. Alternatively, a script or an automated process may beexecuted to identify instances of instrumented software that satisfyparticular criteria corresponding to properties of a metadata object.For example, a crawler may be executed to identify all servers executingin datacenter “east” and associate them with metadata object 310 b.

Set 410 c represents all data streams associated with the properties“critical:true” and “metric:errors.” Accordingly, set 410 c is a subsetof all data centers of set 410 a. This is so because there may beadditional data streams that satisfy “critical:true” but do not satisfy“metric:errors.” Note that the sets 410 a and 410 b may include someoverlapping data streams but are not required to. Similarly, sets 410 cand 410 d may include some overlapping data streams but are not requiredto. As shown in FIG. 4, the sets 410 a and 410 b include someoverlapping data streams and similarly, sets 410 c and 410 d includesome overlapping data streams. The set 410 e includes a subset of theintersection set of sets 410 c and 410 d since it defines a property“administrator “admin1” in addition to the inherited properties. If set410 e did not define properties in addition to the inherited properties,the set 410 e would be the intersection set of sets 410 c and 410 d.

In general a set corresponding to a metadata object X is theintersection of sets corresponding to the metadata objects above themetadata object X in the hierarchy if the metadata object X does notdefine any new properties in addition to the inherited properties.Furthermore, a set corresponding to a metadata object Y may be a subsetof the intersection of sets corresponding to the metadata objects abovethe metadata object Y in the hierarchy if the metadata object Y definesnew properties in addition to the inherited properties.

In some embodiments, the instrumentation analysis system 100 receivesmapping from some metadata objects to sets of data streams. The metadatamodule 220 determines the elements of a set of data streams associatedwith a metadata object based on sets of data streams mapped to othermetadata objects below the metadata object in the hierarchy. Forexample, the metadata module 220 determines the set of all data streamsassociated with a metadata object based on the union of sets of datastreams mapped to metadata objects below the metadata object in thehierarchy. For example, in FIGS. 3 and 4, the metadata module 220receives mappings from each metadata object 310 to one or more datastreams. The metadata module 220 determines the set of data streamsassociated with the metadata object 310 a as the union of data streamsmapped to metadata objects 310 a, 301 c, and 310 e.

The hierarchical definition of the metadata objects makes it easy toassign data centers to various properties and also to define newmetadata objects. The analytics engine 270 receives and processesexpressions based on properties defined in metadata objects. Theanalytics engine 270 determines a set of data streams applicable to anexpression. For example, if the analytics engine 270 receives anexpression specifying computation of a 95^(th) percentile of all datastreams that satisfy “critical:true”, the analytics engine 270determines the 95^(th) percentile of all data streams corresponding tometadata object 310 a, i.e., the set 410 a. If the analytics engine 270receives an expression specifying computation of a 95^(th) percentile ofall data streams that satisfy “critical:true” and “metric:errors”, theanalytics engine 270 determines the 95^(th) percentile of all datastreams corresponding to metadata object 310 c, i.e., the set 410 c.

Whenever the metadata is modified, instrumentation analysis system 100determines all data streams applicable to the modified metadata andupdates index structures that associate metadata with data streams. Forexample, if a new tag (i.e., a property or name-value pair) is definedand associated with a set of data streams, the instrumentation analysissystem 100 updates the indexes that associate the tag with the datastreams. Note that a modification to a metadata object in the hierarchyof metadata objects (e.g., as shown in FIG. 3) at a high level in thehierarchy may affect multiple metadata objects below that metadataobject in that hierarchy. The instrumentation analysis system 100updates the indexes associating each of these metadata objects that isaffected with the appropriate data streams.

Overall Process

FIG. 5 shows the overall process for generating reports based oninstrumented software, according to an embodiment. The metadata module220 receives 510 metadata describing data streams. The metadatadefinition is received independent of the data of the data streamsthemselves. For example, the data stream may provide tuples comprising adata value and a timestamp associated with the data value withoutproviding values for attributes describing the data stream as specifiedin the metadata (for example, datacenter attribute.) The metadata module220 receives the properties describing the data streams from a sourcedifferent from the source providing the data stream. For example, thedata streams are provided by instances of instrumented software that isexecuting, whereas the metadata definition is provided by a systemadministrator via the administration system 160.

The analytics engine 270 receives 520 an expression based on themetadata, for example, an expression that uses the properties specifiedin the metadata. The expression received 520 may be part of a query, forexample, a query received by the instrumentation analysis system 100 togenerate reports describing the instrumented software and provide theresults in real-time, i.e., as the data of the data streams is received.

An example expression generates a value based on an aggregate of datafrom a plurality of data streams. For example, the expression maygenerate a value based on a fixed percentile of a data from a pluralityof data streams, or the expression may generate a value that is amaximum (or minimum, or average, or any other statistical measure) ofdata from a plurality of data streams. Another example expressionsaggregates data from a plurality of streams and groups the data valuesby a metadata attribute, thereby generating a plurality of output datastreams (assuming the metadata attribute can take multiple data valuesand the plurality of input data streams include data streams associatedwith a plurality of data values of the metadata attribute.

The instrumentation analysis system 100 repeats the following steps(530, 540, 550, and 560) as data of various data streams is received bythe instrumentation analysis system 100 from various development systems120. The interface module 210 analyzes 530 the received expression toidentify the data streams applicable to the expression. For example, ina particular time interval the interface module 210 may determine that afirst set of data streams is applicable to the expression. However in asecond (and subsequent) time interval, the interface module 210 maydetermine that a second set of data streams is applicable to theexpression. For example, if the expression evaluates certain valuesbased on data streams that arrive from datacenter “east” as specifiedusing the property datacenter=east, the number of data streams receivedmay increase (as new instances of software are executed by servers inthe data center) or the number of data streams received may decrease (ifsome servers are down).

The interface module 210 analyzes 530 the expression periodically toidentify all data streams applicable to the expression. In anembodiment, the rate at which the interface module 210 analyzes 530 thereceived expression is different from the rate at which the remainingsteps 540, 550, and 560 are performed. For example, the rate at whichthe interface module 210 analyzes 530 the received expression may beslower than the rate at which the remaining steps 540, 550, and 560 areperformed.

In an embodiment, the instrumentation analysis system 100 updates theset of data streams associated with an expression as soon as a datastream is available that is applicable to the expression. Theinstrumentation analysis system 100 maintains a representation of a setof data streams associated with each expression being evaluated. As soonas a new data stream is registered or data for a data stream is receivedthat is applicable to an expression, the instrumentation analysis system100, the instrumentation analysis system 100 adds the data stream to theset of data streams associated with the expression. Similarly, if a datastream is no longer applicable to the expression, the instrumentationanalysis system 100 removes the data stream from the set of data streamsassociated with the instrumentation analysis system 100. For example, adata stream may not be associated with an expression if the metadatadescribing the data stream is modified. Accordingly, the instrumentationanalysis system 100 does not have to evaluate the set of data streamsapplicable to an expression periodically. The set of data streamsapplicable to each expression is determined as soon as a change to theinput data streams occurs that causes the data streams associated withan expression to change.

The interface module 210 receives 540 data points (represented as tuplesof values) of different data streams. In an embodiment, the interfacemodule 210 waits for a fixed interval of time, for example, 1 second orfew seconds and collects all data received from different data streamsduring the fixed time interval. In an embodiment, the quantizationmodule 240 performs quantization of the data for each time interval.Accordingly, data from each data stream is aggregated into a singlevalue associated with the data stream for the time interval. Arepresentation of the quantized data stream is maintained including anin-memory representation of data that arrives from the sources of thedata stream as well as older data values that are stored as a datastream or time series in the time series data store 260.

The analytics engine 270 evaluates 550 the expression based on the dataof the data streams for the time interval. If the data is quantized foreach data stream, the analytics engine 270 evaluates 550 the expressionusing the quantized values from each data stream. The analytics engine270 sends 560 the result(s) of evaluation of the expression forpresentation, for example, to a user interface.

The analytics engine 270 also stores the output data stream (or datastreams) obtained as a result of evaluating the expression, for example,in the time series data store 260. In an embodiment, the analyticsengine 270 creates a new data stream representing the each output datastream obtained as a result of evaluating the expression. The new datastream is stored in the time series data store 260. This allows theresult of the expression to be used as input to other expressions. Forexample, an expression may represent the 95^(th) percentile of valuesreceived as a plurality of data streams. The result of the expressionmay be stored in the time series data store 260 as a new data stream.The analytics engine 270 may further execute an expression that computesa moving average value based on the generated data stream.

In an embodiment, the instrumentation analysis system 100 executes a job(or process) to evaluate the received expression and execute the steps530, 540, 550, and 560. This job dynamically evaluates a query todetermine the instances of MTS objects (and the associated data streams)corresponding to an expression. All data streams that match the querybased on the expression are determined. The data points of the matchingdata streams are considered while evaluating the expression.

Quantization

The instrumentation analysis system 100 performs quantization of thedata streams by processing data streams having data values that arriveat irregular time intervals and generating an equivalent data streamthat has data at regular time intervals. Data values of a data streamarrive at irregular time intervals if the time interval between twoconsecutive pairs of data values is different. For example, the timeinterval between arrival of values v1 and v2 is different from the timeinterval between arrival of values v2 and v3.

The quantization of input data streams simplifies processing of datausing the quantized data streams. For example, aggregate values based onmultiple data streams received can be determined for each time intervalby simply aggregating the single data value for the time interval fromeach quantized data stream. Furthermore, the instrumentation analysissystem 100 uses the same set of quantized data streams for evaluatingdifferent expressions corresponding to different reports. As a result,the computation performed for aggregating the data values for performingthe quantization is reused for evaluation of each expression for eachfixed time interval.

In an embodiment, the instrumentation analysis system 100 performsquantization of an input data stream at the end of each fixed timeinterval so that the quantized data for the time interval is availablefor processing for that fixed time interval. Furthermore, theinstrumentation analysis system 100 stores the quantized data streams sothat data across multiple data streams can be combined in various ways.In other words, a user may send a first request that combines dataacross a set of data streams in a first manner; subsequently the usermay send a new request for combining the data across a different set ofdata streams in a different manner. If the two sets of data streams areoverlapping, the data value for the time interval for the overlappingdata streams can be reused for the two computations.

As an example, the instrumentation analysis system 100 may receive andprocess a report that combines data across a plurality of data streamsto view aggregates computed over various data centers. However,subsequently the user may change the request to view aggregates computedover different types of applications, different types of servers,different geographical regions, and so on. The instrumentation analysissystem 100 reuses the data values of the quantized data streams for eachof these computations.

The instrumentation analysis system 100 may also receive a request inwhich the user modifies the set of data streams over which previous anexpression aggregating data of data streams is evaluated. For example,the user may request the instrumentation analysis system 100 to removeone or more data streams from the set of data streams and request anaggregate based on the revised set. A user may send such a request toanalyze the impact of removing or adding a new server, application, ormaking any other modification to the system configuration. Theinstrumentation analysis system 100 keeps the quantized data streams (orquantized time series data) and combines the quantized data streams fordifferent time intervals based on these requests. Since theinstrumentation analysis system 100 stores the quantized data streams,the instrumentation analysis system 100 has the ability to efficientlycombine data across data streams as needed.

The instrumentation analysis system 100 can combine data across datastreams to perform moving aggregate calculations across multiple datastreams. The instrumentation analysis system 100 may continuouslycompute any moving aggregate value across a given length of timeinterval, for example, one hour moving average, a 15 minute movingaverage, and so on.

Architecture of Quantization Module

The quantization module 240 aggregates the values of the input datastreams for each time interval and generates an aggregate value for thetime interval. Accordingly, the quantization module 240 receives a datastream in which data values can occur after arbitrary time intervals.The quantization module 240 processes the input data stream to generatea data stream in which the data is available at regular time intervals.The details of the quantization module 240 are further described herein.

The quantization module 240 receives information describing the type ofvalue received in the data stream, for example, whether the value is acount of certain action or entities, whether the value was obtained byan aggregation of certain value, whether the value represents amaximum/minimum value of a given set of values, and so on. A data streamis associated with a type of value describing the type of operationsperformed by the instrumented software to obtain the value. Examples ofvarious types of values of data streams received and processed byquantization module 240 include values obtained as a result ofperforming statistical operations such as count (cardinality), average,median, percentile, latest value, and so on. The statistical operationsare performed on values describing entities represented in instrumentedsoftware or actions performed by the instrumented software.

In an embodiment, the quantization module 240 stores a mapping from thevarious types of values of the data stream to the type of operationperformed on the input values of the data stream for an interval toobtain the result value corresponding to a fixed time interval of thequantized data stream. The mapping may be stored as a structure orencoded within the instructions of the quantization module 240, forexample, as a sequence of if, then, else commands. For example, thequantization module 240 may be configured to include instructions of theform, if the data stream is associated with a type of operation “count”,then perform a first function, else if the data stream is associatedwith a type of operation “sum”, then perform a second function, and soon.

In an embodiment, the quantization module 240 includes a buffer forstoring data values that are received as input for a particular timeinterval. The buffer of the quantization module 240 uses a datastructure configured to store arbitrary number of values since thenumber of values received in a time interval is not known in advance andcan change from one time interval to another. For example, thequantization module 240 may use a list data structure or a stack datastructure for storing the values of the input data stream.

The quantization module 240 collects the data values of the data streamreceived for each fixed time interval. The quantization module 240stores a constant value L representing the length of the fixed timeinterval. The quantization module 240 tracks the time since a previousfixed time interval was closed to determine the length of the currenttime interval. The quantization module 240 compares the length of thecurrent time interval with L to determine when the end of the currenttime interval is reached. The quantization module 240 processes all thedata values received in the current time interval to determine theaggregate value representing the current time interval.

The quantization module 240 stores the aggregate value as representingthe quantized data stream value for the fixed time intervalcorresponding to the current time interval. The quantization module 240subsequently clears the buffer used for representing the input values ofthe current time interval and uses it to store the values for next fixedtime interval. In an embodiment, the quantization module 240 usesmultiple buffers so that while the data of a previous time intervalstored in a buffer is being processed, new data for the next timeinterval can be stored in another buffer.

FIG. 6 illustrates the process of quantization of the data streamsreceived from instrumented software, according to an embodiment. FIG. 6shows time axes 620 a and 620 b, each representing a time line withseries of data values. The time axis 620 a shows the data values of theinput data stream 600 and time axis 620 b shows the data stream of theresulting values of the quantized data stream 610 generated by thequantization module 240.

The time intervals I1, I2, I3, etc. represent the fixed time intervalscorresponding to the quantized data stream. As shown in FIG. 6, fourdata values D11, D12, D13, and D14 are received in the time interval I1(representing the time from T0 to T1); two data values D21 and D22 arereceived in the time interval I2 (representing the time from T1 to T2);and three data values D31, D32, and D33 are received in the timeinterval I3 (representing the time from T2 to T3).

A time interval between Tm and Tn may be assumed to include the starttime point Tm (such that the end time point Tn is included in the nexttime interval). Any other interpretation of the time interval between Tmand Tn may be used, for example, the end time point Tn included in thetime interval and the start time point Tm included in the previous timeinterval.

The quantization module 240 processes the data values of each timeinterval to generate the corresponding result value shown in the timeaxis 620 b. For example, the quantization module 240 aggregates thevalues D11, D12, D13, and D14 received in the time interval I1 togenerate the value D1 shown in time axis 620 b; the quantization module240 aggregates the values D21 and D22 received in the time interval I2to generate the value D2 shown in time axis 620 b; and the quantizationmodule 240 aggregates the values D31, D32, and D33 received in the timeinterval I3 to generate the value D3 shown in time axis 620 b.

In an embodiment, the quantization module 240 receives configurationparameters (for example, user defined configuration parameters) thatdefine a quantization policy that defines how the data should bequantized. Different types of data maybe quantized differently. In otherwords, the type of operation performed to aggregate the input values ofthe data stream depends on the type of data represented by the inputdata stream.

If each tuple of the input data stream is a count of certain value, forexample, a count of actions performed by the software, the quantizationmodule 240 aggregates the input values to determine the output datastream value for each time interval by adding the counts. If each tupleof the input data stream received is a minimum (or maximum) of a set ofvalues, the quantization module 240 aggregates the input values for atime interval to determine the output value for that time interval bydetermining the minimum (or maximum) of the input values for the timeinterval. If each tuple of the input data stream received is the latestvalue from a set of values, the quantization module 240 aggregates theinput values for a time interval to determine the output value for thattime interval by determining the latest of the input values for the timeinterval (and ignoring the previous values received during the timeinterval). If each tuple of the input data stream received is an averageof a set of values, the quantization module 240 may aggregate the inputvalues associated with the time interval to determine the output datastream value for each time interval by determining an average of theinput values of the time interval. The average of a set of averages isnot necessarily the average of the inputs used for determining the setof averages.

In an embodiment, the quantization module 240 aggregates the inputvalues comprising a set of averages by selecting the latest value fromthe set. If each tuple of the input data stream received is the lastavailable value of the metric at that point in time, the quantizationmodule 240 aggregates the input values for the time interval todetermine the output value for that time interval by simply using thelast value of the data stream.

In an embodiment, the input data streams comprise data valuesrepresenting averages of certain input values. Each data value isrepresented as a tuple that includes a count of the data values used todetermine the average. The tuple may include an average value and acount of number of data values used to determine the average. Thequantization module 240 determines an overall average value based on aplurality of tuples as follows. The quantization module 240 determines asum value for each tuple by multiplying the average value with the countvalue. The quantization module 240 determines an overall sum value for aplurality of input tuples by determining adding the sum values for eachtuple. The quantization module 240 determines an overall count value byadding the count values of the tuples. The quantization module 240determines the overall average value by dividing the overall sum valueby the overall count value.

Alternatively, each tuple may include a sum and a count of values usedto determine the sum. The quantization module 240 can determine eachindividual average values corresponding to each tuple by dividing thesum value by the count value. The quantization module 240 combines thetuples to determine an overall average value as follows. Thequantization module 240 adds all the sum values to determine an overallsum value. The quantization module 240 adds all the count values todetermine an overall count value. The quantization module 240 determinesthe overall average value by dividing the overall sum value by theoverall count value.

In some embodiments, the quantization module 240 performs rollupoperations. The rollup operation corresponds to further aggregating dataover larger time intervals (referred to herein as a rollup timeinterval). For example, assume that the quantization module 240 performsquantization so as to transform an input data stream with data arrivingirregularly at various time intervals to a data stream with dataavailable at one second time interval. The quantization module 240 mayfurther perform rollup operations to aggregate data across a larger timeinterval, i.e., the rollup time interval, for example, time intervals ofone minute.

In an embodiment, the rollup operation is performed at the end of therollup time interval. This allows the instrumentation analysis system100 to keep rollup data ready for each data stream so that theinstrumentation analysis system 100 can perform a rollup operationacross multiple data streams efficiently. As described above, theinstrumentation analysis system 100 can efficiently combine rollup dataacross multiple data streams in different ways, i.e., a different typeof function used for rollup, a different combination of data streams,different sets across which rollup is performed. In an embodiment, thelength of time intervals across which the quantization module 240performs quantization or rollups is configurable.

FIG. 7 shows the overall process for combining data of data streamsreceived from various sources, according to an embodiment. Stepsdescribed herein may be performed by modules other than those indicated.Furthermore, certain steps may be performed in an order different fromthat indicated in FIG. 7.

This instrumentation analysis system 100 receives data streams frommultiple development systems 120 and combines the data of the datastream as the data is received so as to generate reports based on thedata in real-time. Accordingly, result values of the reportcorresponding to input data streams are generated and sent forpresentation on an ongoing basis as the data is received. For example,the data values of data streams for each time interval are received andthe result values computed and sent for presentation before the resultvalue for the subsequent time interval are processed. Alternatively, thedata values for the next time interval may be received and processed inparallel while the result values for the current time interval are sentfor presentation. FIG. 7 shows the steps that are repeated for each timeinterval.

The interface module 210 receives 710 data from one or more datastreams. For example, the interface module receives 710 a, 710 b, 710 cdata for a first data stream, second data stream, third data stream andso on. The quantization module 240 quantizes 720 data received for eachdata stream for a time interval. For example, the quantization module240 quantizes 720 a, 720 b, 710 c data for the first data stream, seconddata stream, third data stream and so on. Accordingly, a quantizedaggregate value is generated based on the data value of each data streamreceived during the time interval.

The analytics engine 270 evaluates 730 an expression that aggregates thequantized data values corresponding to the data streams for the timeinterval. The expression may be specified using metadata describing thedata streams stored in the metadata store 230. The analytics engine 270stores 740 the result of evaluation of the expression in the time seriesdata store 260. In an embodiment, the analytics engine 270 sends theoutput data stream obtained as a result of evaluation of the expressionfor presentation.

The above steps 710, 720, 730, and 740 are repeated by theinstrumentation analysis system 100 for each subsequent time interval.As a result, a new data stream representing the result of the expressionreceived by the analytics engine 270 is generated and stored in the timeseries data store 260. Furthermore, a result of the expression is sentfor display in real-time for each fixed time intervals as the data foreach time interval is received from the input data streams.

Alternative Embodiments

Although embodiments described herein disclose analysis of data streamsreceived from instrumented software, the techniques disclosed hereinapply to other types of data streams. For example, the instrumentationanalysis system 100 may be used to analyze data streams representingdata generated by sensors, data streams representing flight trackinginformation, data streams representing astronomical informationgenerated by sensors, data streams representing weather information andso on. The instrumentation analysis system 100 allows users to definemetadata attributes describing data streams that are not provided by thedata streams themselves. Accordingly, any number of metadata attributescan be defined describing the data streams by a source independent ofthe sources of data streams themselves. Furthermore, the instrumentationanalysis system 100 can receive specifications of expressions based onmetadata attributes as well as attributes received as part of the datastreams. Real time reports based on such expressions can be generatedand presented via user interfaces.

In an embodiment, several sensors register with the instrumentationanalysis system 100 providing information identifying each sensor. Eachsensor sends a data stream to the instrumentation analysis system 100.The instrumentation analysis system 100 further receives metadatadescribing data streams that specifies attributes describing the datastreams that are not provided with the data stream. For example, themetadata attribute may specify a geographic location of the sensor, mayassociate an organization or a group within the organization with thesensor, may associate one or more user names with each sensor, amanufacturer name with each sensor, and so on. The instrumentationanalysis system 100 further receives expressions defining reports basedon the sensor data and one or more metadata attributes. Theinstrumentation analysis system 100 quantizes each data stream based ona fixed time interval. The instrumentation analysis system 100 furtherevaluates the expression periodically and sends the results as an outputdata stream for display via a user interface.

An example report generated by the instrumentation analysis system 100using the sensor data determines sum of data values received from thesensors grouped by various locations, for example, each locationassociated with a manufacturing facility, where the sensors provideddata associated with certain manufacturing process. Another examplereport generated by the instrumentation analysis system 100 using thesensor data determines a count of active sensors grouped bymanufacturers of each sensor, assuming the instrumentation analysissystem 100 can differentiate active sensors from faulty sensors based ondata streams received (or based of lack of data streams expected from asensor.) An example report generated by the instrumentation analysissystem 100 using the sensor data determines a measure of activity basedon sensor data grouped by groups within an organization (assumingdifferent sensors are associated with groups of the organization.) Theseexamples illustrate how techniques disclosed herein can be applied todata streams received from sources other than instrumented software.

It is to be understood that the figures and descriptions of the presentinvention have been simplified to illustrate elements that are relevantfor a clear understanding of the present invention, while eliminating,for the purpose of clarity, many other elements found in a typicalsystem. Those of ordinary skill in the art may recognize that otherelements and/or steps are desirable and/or required in implementing thepresent invention. However, because such elements and steps are wellknown in the art, and because they do not facilitate a betterunderstanding of the present invention, a discussion of such elementsand steps is not provided herein. The disclosure herein is directed toall such variations and modifications to such elements and methods knownto those skilled in the art.

Some portions of above description describe the embodiments in terms ofalgorithms and symbolic representations of operations on information.These algorithmic descriptions and representations are commonly used bythose skilled in the data processing arts to convey the substance oftheir work effectively to others skilled in the art. These operations,while described functionally, computationally, or logically, areunderstood to be implemented by computer programs or equivalentelectrical circuits, microcode, or the like. Furthermore, it has alsoproven convenient at times, to refer to these arrangements of operationsas modules, without loss of generality. The described operations andtheir associated modules may be embodied in software, firmware,hardware, or any combinations thereof.

As used herein any reference to “one embodiment” or “an embodiment”means that a particular element, feature, structure, or characteristicdescribed in connection with the embodiment is included in at least oneembodiment. The appearances of the phrase “in one embodiment” in variousplaces in the specification are not necessarily all referring to thesame embodiment.

Some embodiments may be described using the expression “coupled” and“connected” along with their derivatives. It should be understood thatthese terms are not intended as synonyms for each other. For example,some embodiments may be described using the term “connected” to indicatethat two or more elements are in direct physical or electrical contactwith each other. In another example, some embodiments may be describedusing the term “coupled” to indicate that two or more elements are indirect physical or electrical contact. The term “coupled,” however, mayalso mean that two or more elements are not in direct contact with eachother, but yet still co-operate or interact with each other. Theembodiments are not limited in this context.

As used herein, the terms “comprises,” “comprising,” “includes,”“including,” “has,” “having” or any other variation thereof, areintended to cover a non-exclusive inclusion. For example, a process,method, article, or apparatus that comprises a list of elements is notnecessarily limited to only those elements but may include otherelements not expressly listed or inherent to such process, method,article, or apparatus. Further, unless expressly stated to the contrary,“or” refers to an inclusive or and not to an exclusive or. For example,a condition A or B is satisfied by any one of the following: A is true(or present) and B is false (or not present), A is false (or notpresent) and B is true (or present), and both A and B are true (orpresent).

In addition, use of the “a” or “an” are employed to describe elementsand components of the embodiments herein. This is done merely forconvenience and to give a general sense of the invention. Thisdescription should be read to include one or at least one and thesingular also includes the plural unless it is obvious that it is meantotherwise.

Upon reading this disclosure, those of skill in the art will appreciatestill additional alternative structural and functional designs for asystem and a process for generating reports based on instrumentedsoftware through the disclosed principles herein. Thus, while particularembodiments and applications have been illustrated and described, it isto be understood that the disclosed embodiments are not limited to theprecise construction and components disclosed herein. Variousmodifications, changes and variations, which will be apparent to thoseskilled in the art, may be made in the arrangement, operation anddetails of the method and apparatus disclosed herein without departingfrom the spirit and scope defined in the appended claims.

We claim:
 1. A method for processing data streams generated byinstrumented software, the method comprising: receiving, a plurality ofinput data streams, each input data stream received from an instance ofinstrumented software executing on an external system, each data streamproviding values of a metric, the values generated at variable timeintervals; receiving a request to periodically evaluate an expressionbased on data values of the input data streams; for each input datastream, identifying a function for aggregating values of the metric ofthe input data stream; generating a plurality of quantized data streamsbased on the input data streams, each quantized data stream comprisingdata values occurring periodically at a fixed time interval, thegenerating comprising, for each fixed time interval, for each input datastream, determining a data value of the quantized data stream for thefixed time interval, comprising: determining an aggregate value byapplying the identified function over data values of the input datastream received within the fixed time interval; and periodicallyevaluating the expression based on data values of the plurality ofquantized data streams.